Model-Driven Development with the jABC

We present the jABC, a framework for model driven application development based on Lightweight Process Coordination. With jABC, users (product developers and system/software designers) easily develop services and applications by composing reusable building-blocks into hierarchical (flow-) graph structures that are executable models of the application. This process is supported by an extensible set of plugins providing additional functionalities, so that the jABC models can be animated, analyzed, simulated, verified, executed and compiled. This way of handling the collaborative design of complex software systems has proven to be effective and adequate for the cooperation of non-programmers and technical people, and it is now being rolled out in the operative practice. 1 Lightweight Process Coordination jABC[2] is a mature framework for service development based on Lightweight Process Coordination [29]. Predecessors of jABC have been used since 1995 to design, among others, industrial telecommunication services [30], Web-based distributed decision support systems [19], and test automation environments for Computer-Telephony integrated systems [16]. jABC allows users to easily develop services and applications by composing reusable building-blocks into (flow-) graph structures. This development process is supported by an extensible set of plugins that provide additional functionality in order to adequately support all the activities needed along the development lifecycle like animation, rapid prototyping, formal verification, debugging, code generation, and evolution. It does not replace but rather enhances other modelling practices like the UML-based RUP (Rational Unified Process, [3,15]), which are in fact used in our process to design the single components. Lightweight Process Coordination (LPC) [29] as a service-oriented, modeldriven development approach, offers a number of advantages that play a particular role when integrating off-the-shelf, possibly remote functionalities: – Simplicity. jABC focuses on application experts, who are typically nonprogrammers. The basic ideas of our modelling process have been explained in past projects to new participants in less than one hour. E. Bin, A. Ziv, and S. Ur (Eds.): HVC 2006, LNCS 4383, pp. 92–108, 2007. c © Springer-Verlag Berlin Heidelberg 2007 Model-Driven Development with the jABC 93 Fig. 1. Layered Architecture of jABC Applications – Agility. We expect requirements, models, and artefacts to change over time, therefore the process supports evolution as a normal process phase. – Customizability. The building blocks which form the model can be freely renamed or restructured to fit the habits of the application experts. – Consistency. The same modelling paradigm underlies the whole process, from the very first steps of prototyping up to the final execution, guaranteeing traceability and semantic consistency. – Verification. With techniques like model checking and local checks we support the user to consistently modify his model. The basic idea is to define local or global properties that the model must satisfy and to provide automatic checking mechanisms. – Service orientation. Existing or external features, applications, or services can be easily integrated into a model by wrapping the existing functionality into building blocks that can be used inside the models. – Executability. The model can have different kinds of execution code. These can be as abstract as textual descriptions (for example in the first animations during requirement capture), and as concrete as the final runtime implementation. – Universality. Thanks to Java as largely platform-independent, objectoriented implementation language, jABC can be easily adopted in a large variety of technical contexts and of application domains. The basic idea of Lightweight Process Coordination is to add a coordination layer to the generally well established three tier architecture. This coordination layer spans the application and services layers of Fig. 1. It is a purely model driven development layer, created and managed within a graphical interactive 94 B. Steffen et al. tool: the Java Application Building Center (jABC). In jABC, users build coordination models by arranging predefined building blocks simply by drag and drop. These basic building blocks are called SIBs (Service Independent Building Block). SIBs have one or more outgoing edges (branches), which depend on the different outcomes of the execution of the functionality represented by the SIB. As an example we may use a SIB called CreateBooking, which prepares a modification in a database. This SIB could have three branches, labelled Successful, DataError and DatabaseError, showing the difference between a correct execution, an error caused by invalid featured data, and an error caused by a problem with the database. Two groups of users work collaboratively on a LPC standard model: – SIB Experts, who are (Java) developers with detailed knowledge about the development of SIBs and appropriate plugin interfaces, and – Application Experts, who have detailed knowledge about the process or application under realization, but are not programmers and may not even have a technical background. As shown in Fig.1, application experts model the business logic of the application from existing SIBs that correspond to components or basic services, and from instances of a special SIB used as placeholder for functionalities not yet implemented. If an application needs additional SIBs, the application expert can use the placeholder to define name, appropriate parameters and branches on his own, using the SIBCreator Plugin. Adding real functionality to the SIB is done in cooperation with the SIB expert, on the basis of the specification of the SIB and possibly also of the business logic model (called Service Logic Graph or SLG) of the application. SIB experts take care of implementing missing SIBs, of the integration of legacy systems and components at the SIB level, and of the persistency layer. Feature-Oriented Descriptions. The terminology SIB and SLG is taken from the context of Intelligent Networks, a successful telecommunications domain which was among the first to standardize a service-oriented architecture and development methodology [23,24], also in connection with features (here seen as basic services). In fact, the jABC methodology instantiates those concepts as follows: Definition [Feature-oriented Description] 1. A feature-oriented service description of a complex service specifies the behaviours of a base system and a set of optional features. 2. The behaviour of each feature and of the basic system are given by means of Service Logic Graphs (SLGs) [24]. 3. The realization of each SLG bases on a library of reusable components called Service Independent Building-Blocks (SIBs). 4. The feature-oriented service description includes also a set of abstract requirements that ensure that the intended purposes are met. Model-Driven Development with the jABC 95 5. Interactions between features are regulated explicitely and are usually expressed via constraints in temporal logics. 6. Any feature composition is allowed that does not violate any constraint. Hierarchy and Refinement. Each SLG model can be wrapped into a single coarser-grained SIB, and may be used on another hierarchical level of modelling. Similarly, each SIB can be refined into an own model, showing a more detailed view on the represented feature. This way we support both a top-down and bottom-up application modelling process. In the remainder of the paper we present the basic components of the complete jABC toolbox. Sect. 2 and 3 give a more detailed overview of the jABC. In Sect. 4 and 5 we focus on the included verification and analysis tools (the localand model checker). The jABC Tracer, used to animate, simulate, interpret, and debug at the coordination level is presented in Sect. 6. In Sect. 7 we present the jABC code generator, which is itself constructed by means of the jABC, as a LPC process. In Sect. 8 we discuss related approaches and in Sect. 9 we present our conclusions. 2 The Java Application Building Center The jABC is meanwhile the fourth generation of this framework [34], with C++ precursors dating back to 1992 [33]. Thanks to Java we are largely platform independent: jABC runs wherever a JVM is available, solving this way many portability and interoperability issues of its precursors. jABC is at the same time used as a commercial product in several projects with industry, and as a teaching and experimental platform for our students. This is possible thanks to a plugin framework concept which supports the easy replacement of almost every part of the system and the easy addition of new (customer-specific) features. Handling Basic Services. Java simplifies the handling of SIB components too a single Java class contains all the required or optional information: – the name is represented by the Java class name, – the parameters are defined as the public fields of the class, – the branches are represented by the reserved field branches, which can be optionally flagged as final, – the graphical representation in the drawing canvas is the picture returned by the getIcon() method, – the online documentation for the SIB, its parameters and branches, are retrieved via the getTooltipText() method, and – optional information for animation, simulation, analysis, etc., are encapsulated with plugin-specific interfaces. For example, the interface Tracer consists of the defined method onTrace(). 96 B. Steffen et al. Fig. 2. jABC Big Picture SIB Palettes as Taxonomies. At runtime, the jABC discovers and analyses the compiled SIB class files and generates a structured representation of the available SIBs for the application experts. The SIBs are presented as a taxonomy, as in Fig. 3(upper left), which shows on the canvas the model of the code generator. This taxonomy is a tree representation of a directed acyclic graph. A SIB can thus appear there several times, even with different names. Different to standard Java classes, the physical class package of the SIB is irrelevant for the jABC: the SIB description achieves this decoupling. The jABC replaces unavailable or deleted SIB classes with the ProxySIB, a specific placeholder, and protects the model from information loss. If the graph is stored again, the information of the missing SIB is kept; if the SIB becomes available again, the model will automatically load the correct SIB. Even after refactoring a SIB class, older models referencing such a SIB will use the correct class. Meaning of the Coordination Graphs. The basic jABC System does not define a standard semantics for graphs: at this point, SLGs are purely structural descriptions that can be printed, layouted, edited, but have no meaning. This meaning is given by different jABC-plugins, like the Tracer already mentioned. The Tracer interprets an SLG as a flow graph with one or more distinguished start nodes and is able to execute it. The Tracer defines an own Java interface that contains File Edit